1. Field of the Invention
The present invention relates to a method for controlling a session for interworking between a converged IP messaging service and a non-converged IP messaging service, and more particularly to a method for controlling a session in such a manner as to initiate a session between a converged IP messaging service and a non-converged IP messaging service, modifying an already initiated session, and so forth.
2. Description of the Related Art
In the existing mobile environment, terminals perform one-shot messages, such as Short Messaging Service (SMS) messages, Multimedia Messaging Service (MMS) messages, and the like, but users expect messaging services that make it easy to talk with others through an instant messenger in a wired environment. Instant messaging services have been introduced into terminals and networks, based on Session Initiation Protocol/Internet Protocol (SIP/IP) core networks. Also, due to the demand for push-to-talk (e.g. walkie-talkie) from customers and enterprises, Push to talk over Cellular (PoC) services and systems based on SIP/IP core networks have been developed. Furthermore, the rapid change in the market including enterprises and communication business increases the need to integrate and process various types of received messages.
In consideration of this, the Open Mobile Alliance (OMA), a standards body that establishes international open standards for mobile solutions and services, has recently developed technical standards for Converged Internet Protocol (IP) Messaging (CPM) services that are implemented through SIP/IP core networks.
The CPM service is an IP Multimedia Subsystem (IMS)-based messaging service that integrates existing messaging services, such as an SMS, an MMS, etc., into a single service and provides the integrated single service, based on an IP. Unlike the existing messaging services in which transmission/reception is possible within limited networks and terminals, the CPM service provides an IP-based converged service regardless of the kinds of terminals, the types of media, the kinds of networks, and the types of services.
Such a CPM service must be able to integrate and process all types of existing messages. Therefore, the CPM service requires mutual conversion between SMS message formats, MMS message formats, instant messaging service message formats, non-CPM message formats (e.g. PoC), and CPM message formats. The mutual conversion between non-CPM message formats and CPM message formats is referred to as “interworking”.
The CPM service supports interworking with various types of non-CPM services. When the sender and receiver of a message belong to different network areas, interworking may be performed in the sender's network or the receiver's network, depending on each service scenario. In order to provide interworking with non-CPM services, a CPM system must configure various network entities. Functions and interrelations of network entities constituting a CPM system will be described with reference to FIG. 1.
FIG. 1 illustrates entities of a CPM system. The CPM system includes a CPM client 110, a CPM server 120, an Interworking Selection Function (ISF) 130, an Interworking Function (IWF) 140, an SIP/IP core network 150, and a remote SIP/IP core network 151. Although a non-CPM client 111 and a non-CPM server 160 are not entities of the CPM system, they are illustrated in the drawing for the purpose of the description of interworking of the CPM system.
The CPM client 110 refers to a CPM service subscriber. The CPM client 110 generates a converged message to send to the CPM server 120, and receives a message, which another CPM client or the non-CPM client 111 sends, from the CPM server 120. The non-CPM client 111 is a client subscribing to a non-CPM service, and exchanges a message with the corresponding non-CPM server 160.
The CPM server 120 processes a message received from the CPM client 110 or another CPM server. To this end, the CPM server 120 determines if interworking is needed. That is, the CPM server 120 determines if interworking is needed for the received message in order to communicate with the non-CPM server 160.
For example, if the CPM server 120 determines that interworking is needed, then the CPM server 120 delivers a received message to the ISF 130. If the CPM server 120 determines that interworking is not needed, then the CPM server 120 delivers a received message to a receiving CPM client or a CPM server to which the receiving CPM client belongs. That is, when a receiving CPM client belongs to the same network area as the CPM server 120, the CPM server 120 delivers a received message to the receiving CPM client. However, when a receiving CPM client belongs to a different network area from the CPM server 120, the CPM server 120 delivers a received message to a CPM server of the different network area. Also, the CPM server 120 delivers a message, received from the ISF 130 or the IWF 140 for interworking, to the non-CPM client 111 corresponding to the destination address of the received message.
The ISF 130 selects a non-CPM server 160 that can most effectively deliver a message, received from the CPM server 120, to a receiving party, and delivers the received message to the IWF 140 that is actually responsible for interworking with the selected non-CPM server 160.
The IWF 140 is a functional entity for providing direct interworking with a non-CPM service, and performs mutual conversion between the formats of CPM and non-CPM service messages to then deliver the converted message to the non-CPM server 160.
The SIP/IP core network 150 is a functional entity for delivering control signals of SIP-based services, messages generated by clients or service entities thereof, etc. to receivers or other entities. To this end, the SIP/IP core network 150 may exchange messages with SIP/IP core networks belonging to other provider areas.
The remote SIP/IP core network 151 is an SIP/IP core network provided and managed by another network provider, and has the same function as the SIP/IP core network 150. Although not illustrated in FIG. 1, entities, devices, and systems for providing CPM and non-CPM services may be implemented in the remote SIP/IP core network 151.
The non-CPM server 160 serves to provide messaging services excluding the CPM service. The messaging services provided by the non-CPM server 150 include an SMS, an MMS, an instant messaging service, PoC, and the like.
Reference will now be made to an interworking operation with reference to FIG. 2. FIG. 2 illustrates message sending/receiving for interworking between a CPM service and a non-CPM service. In particular, FIG. 2 shows message sending/receiving on the assumption that a sending CPM client 110 requests a receiving non-CPM client 111 to set up a session, and any media type requested by the CPM client 110 can be processed in any single IWF.
In step 201, the CPM client 110 sends to a CPM server 120 an INVITE message requesting session initiation. The INVITE message includes necessary information for session initiation in the form of a Session Description Protocol (SDP).
In step 203, on receiving the INVITE message from the CPM client 110, the CPM server 120 checks if the receiving client is a CPM service subscriber and is in an available state, thereby determining if interworking is needed. Interworking is needed when the receiving client is a non-CPM client, and is not needed when the receiving client is a CPM client and is in an available state, or the receiving client is a CPM client and is in an unavailable state. It is assumed here that the receiving client is a non-CPM client 111. Thus, in step 205, the CPM server 120 delivers to the ISF 130 the INVITE message. However, if interworking is not needed, then a different operation is performed. That is, when the receiving client is a CPM client and is in an available state, the INVITE message is delivered to the receiving CPM client to initiate a session. Also, when the receiving client is a CPM client and is in an unavailable state, the INVITE message may be deleted, temporarily stored in the CPM server 120, or delivered to the ISF 130 for message forwarding through the non-CPM service, according to user settings. However, this scenario is not illustrated in the drawing.
In consideration of the presence and preference of the receiving client, media types requested by the INVITE message, a service to which the receiving client subscribes, etc., the ISF 130 selects in step 207 an IWF 140 that is most suitable to perform interworking between the CPM service and the non-CPM service, and delivers the INVITE message to the selected IWF 140 in step 209. The presence refers to information including the type of a service to which a client subscribes, and the preference refers to user settings, etc.
In step 211, on receiving the INVITE message, the IWF 140 determines if it can support media types which are included in the INVITE message and for which session initiation is requested. Assuming that the IWF 140 can support the requested media types, in step 211, the IWF 140 converts the received INVITE message into a non-CPM message, based on a format suitable for the non-CPM service. For reference, the INVITE message is converted as follows: a specific header, parameter, or SDP body in the INVITE message is adapted to the corresponding non-CPM message format when the non-CPM service supportable by the IWF 140 is an SIP-based service, such as SIMPLE IM, POC, etc., and the INVITE message is converted into a message format suitable for the protocol of the corresponding non-CPM service when the non-CPM service supportable by the IWF 140 is a non-SIP-based service, such as an SMS, an MMS, etc.
If none of the requested media types can be supported by the IWF 140, then the IWF 140 sends a corresponding response message (e.g. “415 Unsupported Media Type”) to the ISF 130. On receiving the “415 Unsupported Media Type” message, the ISF 130 may deliver the message to the sending CPM client 110 via the CPM server 120, or select another IWF and retry interworking, depending on the service policy. Also, if some of the requested media types can be supported by the IWF 140, then the session request for unsupported media types is omitted in the process of the message conversion.
In step 213, the IWF 140 delivers the converted non-CPM message to the corresponding non-CPM server 160, which in turn delivers the converted non-CPM message to the receiving non-CPM client 111 in step 215. In steps 217 and 219, the non-CPM client 111 delivers a response message to the IWF 140 via the non-CPM server 160, in response to the non-CPM message received from the non-CPM server 160.
In step 221, the IWF 140 converts the response message, received via the non-CPM server 160, into a message suitable for the CPM message format, for example, an OK message according to the SIP message format, and then in step 223, delivers the converted response message to the ISF 130. In step 225, the ISF 130 delivers the converted response message to the CPM server 120.
In step 227, the CPM server 120 initiates a session for allowed media types with the IWF 140, and then in step 229, sends an OK message, a response message to the session initiation message in step 201, to the sending CPM client 110. Subsequently, in step 231, the CPM client initiates a session for sending/receiving of the allowed media types with the CPM server 120.
However, the above-mentioned interworking operation in the conventional CPM system has the following problem. When only some of media types requested by the CPM client 110 can be supported by the IWF 140, interworking is not performed for unsupported media types, and thus they cannot be provided with the CPM service, as described in step 211. Since this leads to a deterioration of the quality of the CPM service, there is a need to minimize such a restriction.